this problem by simply offering the appropriate feature to users of the
respective systems. This approach treats users of various Fortran
systems and dialects as remote "islands", or camps, of programmers, and
assume that these camps rarely come into contact with each other (or,
especially, with each other's code).
Project GNU takes a radically different approach to software and
language design, in that it assumes that users of GNU software do not
necessarily care what kind of underlying system they are using,
regardless of whether they are using software (at the user-interface
level) or writing it (for example, writing Fortran or C code).
As such, GNU users rarely need consider just what kind of underlying
hardware (or, in many cases, operating system) they are using at any
particular time. They can use and write software designed for a
general-purpose, widely portable, heterogenous environment--the GNU
environment.
In line with this philosophy, GNU Fortran must evolve into a product
that is widely ported and portable not only in the sense that it can be
successfully built, installed, and run by users, but in the larger
sense that its users can use it in the same way, and expect largely the
same behaviors from it, regardless of the kind of system they are using
at any particular time.
This approach constrains the solutions `g77' can use to resolve
conflicts between various camps of Fortran users. If these two camps
disagree about what a particular construct should mean, `g77' cannot
simply be changed to treat that particular construct as having one
meaning without comment (such as a warning), lest the users expecting
it to have the other meaning are unpleasantly surprised that their code
misbehaves when executed.
The use of the ASCII backslash character in character constants is
an excellent (and still somewhat unresolved) example of this kind of
controversy. *Note Backslash in Constants::. Other examples are
likely to arise in the future, as `g77' developers strive to improve
its ability to accept an ever-wider variety of existing Fortran code
without requiring significant modifications to said code.
Development of GNU Fortran is further constrained by the desire to
avoid requiring programmers to change their code. This is important
because it allows programmers, administrators, and others to more
faithfully evaluate and validate `g77' (as an overall product and as
new versions are distributed) without having to support multiple
versions of their programs so that they continue to work the same way
on their existing systems (non-GNU perhaps, but possibly also earlier
versions of `g77').
File: g77.info, Node: Standard Support, Next: Conformance, Prev: Direction of Language Development, Up: Language
ANSI FORTRAN 77 Standard Support
================================
GNU Fortran supports ANSI FORTRAN 77 with the following caveats. In
summary, the only ANSI FORTRAN 77 features `g77' doesn't support are
those that are probably rarely used in actual code, some of which are
explicitly disallowed by the Fortran 90 standard.
* Menu:
* No Passing External Assumed-length:: CHAR*(*) CFUNC restriction.
* No Passing Dummy Assumed-length:: CHAR*(*) CFUNC restriction.
* No Pathological Implied-DO:: No `((..., I=...), I=...)'.
* No Useless Implied-DO:: No `(A, I=1, 1)'.
File: g77.info, Node: No Passing External Assumed-length, Next: No Passing Dummy Assumed-length, Up: Standard Support
No Passing External Assumed-length
----------------------------------
`g77' disallows passing of an external procedure as an actual
argument if the procedure's type is declared `CHARACTER*(*)'. For
example:
CHARACTER*(*) CFUNC
EXTERNAL CFUNC
CALL FOO(CFUNC)
END
It isn't clear whether the standard considers this conforming.
File: g77.info, Node: No Passing Dummy Assumed-length, Next: No Pathological Implied-DO, Prev: No Passing External Assumed-length, Up: Standard Support
No Passing Dummy Assumed-length
-------------------------------
`g77' disallows passing of a dummy procedure as an actual argument
if the procedure's type is declared `CHARACTER*(*)'.
SUBROUTINE BAR(CFUNC)
CHARACTER*(*) CFUNC
EXTERNAL CFUNC
CALL FOO(CFUNC)
END
It isn't clear whether the standard considers this conforming.
File: g77.info, Node: No Pathological Implied-DO, Next: No Useless Implied-DO, Prev: No Passing Dummy Assumed-length, Up: Standard Support
No Pathological Implied-DO
--------------------------
The `DO' variable for an implied-`DO' construct in a `DATA'
statement may not be used as the `DO' variable for an outer
implied-`DO' construct. For example, this fragment is disallowed by
`g77':
DATA ((A(I, I), I= 1, 10), I= 1, 10) /.../
This also is disallowed by Fortran 90, as it offers no additional
capabilities and would have a variety of possible meanings.
Note that it is *very* unlikely that any production Fortran code
tries to use this unsupported construct.
File: g77.info, Node: No Useless Implied-DO, Prev: No Pathological Implied-DO, Up: Standard Support
No Useless Implied-DO
---------------------
An array element initializer in an implied-`DO' construct in a
`DATA' statement must contain at least one reference to the `DO'
variables of each outer implied-`DO' construct. For example, this
fragment is disallowed by `g77':
DATA (A, I= 1, 1) /1./
This also is disallowed by Fortran 90, as FORTRAN 77's more permissive
requirements offer no additional capabilities. However, `g77' doesn't
necessarily diagnose all cases where this requirement is not met.
Note that it is *very* unlikely that any production Fortran code
tries to use this unsupported construct.
File: g77.info, Node: Conformance, Next: Notation Used, Prev: Standard Support, Up: Language
Conformance
===========
(The following information augments or overrides the information in
Section 1.4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
language. Chapter 1 of that document otherwise serves as the basis for
the relevant aspects of GNU Fortran.)
The definition of the GNU Fortran language is akin to that of the
ANSI FORTRAN 77 language in that it does not generally require
conforming implementations to diagnose cases where programs do not
conform to the language.
However, `g77' as a compiler is being developed in a way that is
intended to enable it to diagnose such cases in an easy-to-understand
manner.
A program that conforms to the GNU Fortran language should, when
compiled, linked, and executed using a properly installed `g77' system,
perform as described by the GNU Fortran language definition. Reasons
for different behavior include, among others:
* Use of resources (memory--heap, stack, and so on; disk space; CPU
time; etc.) exceeds those of the system.
* Range and/or precision of calculations required by the program
exceeds that of the system.
* Excessive reliance on behaviors that are system-dependent
(non-portable Fortran code).
* Bugs in the program.
* Bug in `g77'.
* Bugs in the system.
Despite these "loopholes", the availability of a clear specification
of the language of programs submitted to `g77', as this document is
intended to provide, is considered an important aspect of providing a
